ரியாக்ட் பேட்ச் செய்யப்பட்ட ஸ்டேட் அப்டேட்கள்: செயல்திறன் மேம்படுத்தப்பட்ட ஸ்டேட் மாற்றங்கள்

நவீன வலை உருவாக்கத்தின் வேகமான உலகில், தடையற்ற மற்றும் பதிலளிக்கக்கூடிய பயனர் அனுபவத்தை வழங்குவது மிக முக்கியமானது. ரியாக்ட் டெவலப்பர்களுக்கு, இந்த இலக்கை அடைய நிலையை (state) திறமையாக நிர்வகிப்பது ஒரு மூலக்கல்லாகும். செயல்திறனை மேம்படுத்த ரியாக்ட் பயன்படுத்தும் சக்திவாய்ந்த, ஆனால் சில நேரங்களில் தவறாகப் புரிந்து கொள்ளப்பட்ட, வழிமுறைகளில் ஒன்று ஸ்டேட் பேட்சிங் ஆகும். ரியாக்ட் பல ஸ்டேட் அப்டேட்களை எவ்வாறு ஒன்றாகக் குழுவாக்குகிறது என்பதைப் புரிந்துகொள்வது உங்கள் பயன்பாடுகளில் குறிப்பிடத்தக்க செயல்திறன் ஆதாயங்களைத் திறக்கும், இது மென்மையான பயனர் இடைமுகங்கள் மற்றும் சிறந்த ஒட்டுமொத்த பயனர் அனுபவத்திற்கு வழிவகுக்கும்.

ரியாக்ட்டில் ஸ்டேட் பேட்சிங் என்றால் என்ன?

சுருக்கமாகச் சொன்னால், ஸ்டேட் பேட்சிங் என்பது ஒரே ஈவென்ட் ஹேண்ட்லர் அல்லது அசிங்க்ரோனஸ் ஆபரேஷனில் நிகழும் பல ஸ்டேட் அப்டேட்களை ஒரே ரீ-ரெண்டரில் குழுவாக்கும் ரியாக்ட்டின் உத்தியாகும். ஒவ்வொரு தனிப்பட்ட ஸ்டேட் மாற்றத்திற்கும் கூறுகளை (component) ரீ-ரெண்டர் செய்வதற்குப் பதிலாக, ரியாக்ட் இந்த மாற்றங்களைச் சேகரித்து அனைத்தையும் ஒரே நேரத்தில் பயன்படுத்துகிறது. இது தேவையற்ற ரீ-ரெண்டர்களின் எண்ணிக்கையைக் கணிசமாகக் குறைக்கிறது, இது பெரும்பாலும் பயன்பாட்டு செயல்திறனுக்கு ஒரு தடையாக இருக்கிறது.

கிளிக் செய்யும் போது, இரண்டு தனித்தனி ஸ்டேட்களைப் புதுப்பிக்கும் ஒரு பட்டன் இருப்பதாகக் கருதுங்கள். பேட்சிங் இல்லாமல், ரியாக்ட் பொதுவாக இரண்டு தனித்தனி ரீ-ரெண்டர்களைத் தூண்டும்: ஒன்று முதல் ஸ்டேட் புதுப்பித்தலுக்குப் பிறகும், மற்றொன்று இரண்டாவதற்குப் பிறகும். பேட்சிங் மூலம், ரியாக்ட் இந்த நெருக்கமாக நிகழும் புதுப்பிப்புகளை புத்திசாலித்தனமாகக் கண்டறிந்து அவற்றை ஒரே ரீ-ரெண்டர் சுழற்சியில் ஒருங்கிணைக்கிறது. இதன் பொருள் உங்கள் காம்பொனென்ட்டின் லைஃப்சைக்கிள் மெத்தட்கள் (அல்லது ஃபங்ஷனல் காம்பொனென்ட் சமமானவை) குறைவான முறை அழைக்கப்படுகின்றன, மேலும் UI மிகவும் திறமையாகப் புதுப்பிக்கப்படுகிறது.

செயல்திறனுக்கு பேட்சிங் ஏன் முக்கியம்?

ஸ்டேட் அல்லது ப்ராப்ஸில் ஏற்படும் மாற்றங்களைப் பிரதிபலிக்க UI ஐப் புதுப்பிப்பதற்கு ரீ-ரெண்டர்கள் முதன்மை வழிமுறையாகும். இது அவசியமானாலும், அதிகப்படியான அல்லது தேவையற்ற ரீ-ரெண்டர்கள் பின்வரும் விளைவுகளுக்கு வழிவகுக்கும்:

• அதிகரித்த CPU பயன்பாடு: ஒவ்வொரு ரீ-ரெண்டரும் ரெக்கன்சிலியேஷன் (reconciliation) செயல்முறையை உள்ளடக்கியது, இதில் ரியாக்ட் உண்மையான DOM இல் எதைப் புதுப்பிக்க வேண்டும் என்பதைத் தீர்மானிக்க முந்தைய விர்ச்சுவல் DOM உடன் ஒப்பிடுகிறது. அதிக ரீ-ரெண்டர்கள் என்றால் அதிக கணக்கீடு.
• மெதுவான UI புதுப்பிப்புகள்: பிரவுசர் அடிக்கடி காம்பொனென்ட்களை ரீ-ரெண்டர் செய்வதில் மும்முரமாக இருக்கும்போது, பயனர் தொடர்புகள், அனிமேஷன்கள் மற்றும் பிற முக்கியமான பணிகளைக் கையாள குறைவான நேரம் கிடைக்கிறது, இது மந்தமான அல்லது பதிலளிக்காத இடைமுகத்திற்கு வழிவகுக்கிறது.
• அதிக நினைவக நுகர்வு: ஒவ்வொரு ரீ-ரெண்டர் சுழற்சியிலும் புதிய ஆப்ஜெக்ட்கள் மற்றும் டேட்டா கட்டமைப்புகளை உருவாக்குவது அடங்கும், இது காலப்போக்கில் நினைவகப் பயன்பாட்டை அதிகரிக்கக்கூடும்.

ஸ்டேட் அப்டேட்களைப் பேட்ச் செய்வதன் மூலம், ரியாக்ட் இந்த விலையுயர்ந்த ரீ-ரெண்டர் செயல்பாடுகளின் எண்ணிக்கையை திறம்படக் குறைக்கிறது, இது அதிக செயல்திறன் மற்றும் மென்மையான பயன்பாட்டிற்கு வழிவகுக்கிறது, குறிப்பாக அடிக்கடி ஸ்டேட் மாற்றங்களைக் கொண்ட சிக்கலான பயன்பாடுகளில்.

ரியாக்ட் ஸ்டேட் பேட்சிங்கை எவ்வாறு கையாளுகிறது (தானியங்கி பேட்சிங்)

வரலாற்று ரீதியாக, ரியாக்ட்டின் தானியங்கி ஸ்டேட் பேட்சிங் முதன்மையாக சிந்தெடிக் ஈவென்ட் ஹேண்ட்லர்களுக்கு மட்டுமே περιορισμένο இருந்தது. அதாவது, ஒரு நேட்டிவ் பிரவுசர் ஈவென்ட்டிற்குள் (கிளிக் அல்லது கீபோர்டு ஈவென்ட் போன்றவை) ஸ்டேட்டைப் புதுப்பித்தால், ரியாக்ட் அந்தப் புதுப்பிப்புகளைப் பேட்ச் செய்யும். இருப்பினும், ப்ராமிஸ்கள், `setTimeout`, அல்லது நேட்டிவ் ஈவென்ட் லிஸனர்களில் இருந்து உருவான புதுப்பிப்புகள் தானாகவே பேட்ச் செய்யப்படவில்லை, இது பல ரீ-ரெண்டர்களுக்கு வழிவகுத்தது.

ரியாக்ட் 18 இல் கன்கரண்ட் மோட் (Concurrent Mode) (இப்போது கன்கரண்ட் அம்சங்கள் என குறிப்பிடப்படுகிறது) அறிமுகப்படுத்தப்பட்டதன் மூலம் இந்த நடத்தை குறிப்பிடத்தக்க அளவில் மாறியது. ரியாக்ட் 18 மற்றும் அதற்குப் பிறகு, ப்ராமிஸ்கள், `setTimeout` மற்றும் நேட்டிவ் ஈவென்ட் லிஸனர்கள் உட்பட எந்தவொரு அசிங்க்ரோனஸ் செயல்பாட்டிலிருந்தும் தூண்டப்படும் ஸ்டேட் அப்டேட்களை ரியாக்ட் தானாகவே பேட்ச் செய்கிறது.

ரியாக்ட் 17 மற்றும் அதற்கு முந்தையவை: தானியங்கி பேட்சிங்கின் நுணுக்கங்கள்

ரியாக்ட்டின் முந்தைய பதிப்புகளில், தானியங்கி பேட்சிங் மிகவும் கட்டுப்படுத்தப்பட்டது. இது பொதுவாக எவ்வாறு செயல்பட்டது என்பது இங்கே:

• சிந்தெடிக் ஈவென்ட் ஹேண்ட்லர்கள்: இதற்குள் உள்ள புதுப்பிப்புகள் பேட்ச் செய்யப்பட்டன. உதாரணமாக:

            import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  const [value, setValue] = useState(0);

  const handleClick = () => {
    setCount(c => c + 1);
    setValue(v => v + 1);
  };

  return (
    

      
Count: {count}
      
Value: {value}
      Increment Both
    
  );
}

export default Counter;
            

              
                Copy
              
            
          

இந்த எடுத்துக்காட்டில், பட்டனை கிளிக் செய்வது ஒரே ஒரு ரீ-ரெண்டரைத் தூண்டும், ஏனெனில் onClick ஒரு சிந்தெடிக் ஈவென்ட் ஹேண்ட்லர் ஆகும்.

• அசிங்க்ரோனஸ் செயல்பாடுகள் (Promises, setTimeout): இதற்குள் உள்ள புதுப்பிப்புகள் தானாகவே பேட்ச் செய்யப்படவில்லை. இது டெவலப்பர்களை லைப்ரரிகள் அல்லது குறிப்பிட்ட ரியாக்ட் பேட்டர்ன்களைப் பயன்படுத்தி கைமுறையாகப் புதுப்பிப்புகளைப் பேட்ச் செய்ய வேண்டியிருந்தது.

            import React, { useState } from 'react';

function AsyncCounter() {
  const [count, setCount] = useState(0);
  const [value, setValue] = useState(0);

  const handleAsyncClick = () => {
    // This will cause two re-renders in React < 18
    setTimeout(() => {
      setCount(c => c + 1);
      setValue(v => v + 1);
    }, 1000);
  };

  return (
    

      
Count: {count}
      
Value: {value}
      Increment After Delay
    
  );
}

export default AsyncCounter;
            

              
                Copy
              
            
          

ரியாக்ட் 18-க்கு முந்தைய பதிப்புகளில், setTimeout கால்பேக் இரண்டு தனித்தனி ரீ-ரெண்டர்களைத் தூண்டும், ஏனெனில் அவை தானாகவே பேட்ச் செய்யப்படவில்லை. இது செயல்திறன் சிக்கல்களின் ஒரு பொதுவான மூலமாகும்.

ரியாக்ட் 18 மற்றும் அதற்குப் பிறகு: உலகளாவிய தானியங்கி பேட்சிங்

ரியாக்ட் 18 ஸ்டேட் பேட்சிங்கில் புரட்சியை ஏற்படுத்தியது, தூண்டுதலைப் பொருட்படுத்தாமல் அனைத்து புதுப்பிப்புகளுக்கும் தானியங்கி பேட்சிங்கை இயக்கியது.

ரியாக்ட் 18-இன் முக்கிய நன்மை:

• நிலைத்தன்மை: உங்கள் ஸ்டேட் புதுப்பிப்புகள் எங்கிருந்து வந்தாலும் - ஈவென்ட் ஹேண்ட்லர்கள், ப்ராமிஸ்கள், `setTimeout` அல்லது பிற அசிங்க்ரோனஸ் செயல்பாடுகள் - ரியாக்ட் 18 அவற்றை தானாகவே ஒரே ரீ-ரெண்டரில் பேட்ச் செய்யும்.

ரியாக்ட் 18 உடன் AsyncCounter எடுத்துக்காட்டை மீண்டும் பார்ப்போம்:

            import React, { useState } from 'react';

function AsyncCounterReact18() {
  const [count, setCount] = useState(0);
  const [value, setValue] = useState(0);

  const handleAsyncClick = () => {
    // In React 18+, this will cause only ONE re-render.
    setTimeout(() => {
      setCount(c => c + 1);
      setValue(v => v + 1);
    }, 1000);
  };

  return (
    

      
Count: {count}
      
Value: {value}
      Increment After Delay (React 18+)
    
  );
}

export default AsyncCounterReact18;
            

              
                Copy
              
            
          

ரியாக்ட் 18 உடன், setTimeout கால்பேக் இப்போது ஒரே ஒரு ரீ-ரெண்டரை மட்டுமே தூண்டும். இது டெவலப்பர்களுக்கு ஒரு மிகப்பெரிய முன்னேற்றம், குறியீட்டை எளிதாக்குகிறது மற்றும் செயல்திறனை தானாகவே மேம்படுத்துகிறது.

கைமுறையாக புதுப்பிப்புகளை பேட்ச் செய்தல் (தேவைப்படும் போது)

ரியாக்ட் 18-இன் தானியங்கி பேட்சிங் ஒரு கேம்-சேஞ்சராக இருந்தாலும், பேட்சிங்கின் மீது உங்களுக்கு வெளிப்படையான கட்டுப்பாடு தேவைப்படும் அரிதான சூழ்நிலைகள் இருக்கலாம், அல்லது நீங்கள் பழைய ரியாக்ட் பதிப்புகளுடன் பணிபுரிந்தால். இந்த நிகழ்வுகளுக்கு, ரியாக்ட் unstable_batchedUpdates செயல்பாட்டை வழங்குகிறது (எனினும் அதன் நிலையற்ற தன்மை, முடிந்தவரை தானியங்கி பேட்சிங்கை விரும்புமாறு நினைவூட்டுகிறது).

முக்கிய குறிப்பு: unstable_batchedUpdates API நிலையற்றதாகக் கருதப்படுகிறது மற்றும் எதிர்கால ரியாக்ட் பதிப்புகளில் அகற்றப்படலாம் அல்லது மாற்றப்படலாம். தானியங்கி பேட்சிங்கை முற்றிலும் நம்ப முடியாத சூழ்நிலைகளில் அல்லது பழைய குறியீடுகளுடன் பணிபுரியும் போது இது முதன்மையாகப் பயன்படுத்தப்படுகிறது. எப்போதும் ரியாக்ட் 18+-இன் தானியங்கி பேட்சிங்கைப் பயன்படுத்த முயற்சிக்கவும்.

அதைப் பயன்படுத்த, நீங்கள் வழக்கமாக அதை react-dom-இலிருந்து (DOM-தொடர்பான பயன்பாடுகளுக்கு) இறக்குமதி செய்து, உங்கள் ஸ்டேட் புதுப்பிப்புகளை அதற்குள் போர்த்திடுவீர்கள்:

            import React, { useState } from 'react';
import ReactDOM from 'react-dom'; // Or 'react-dom/client' in React 18+

// If using React 18+ with createRoot, unstable_batchedUpdates is still available but less critical.
// For older React versions, you'd import from 'react-dom'.

function ManualBatchingExample() {
  const [count, setCount] = useState(0);
  const [value, setValue] = useState(0);

  const handleManualBatchClick = () => {
    // In older React versions, or if auto-batching fails for some reason,
    // you might wrap updates here.
    ReactDOM.unstable_batchedUpdates(() => {
      setCount(c => c + 1);
      setValue(v => v + 1);
    });
  };

  return (
    

      
Count: {count}
      
Value: {value}
      Manual Batch Increment
    
  );
}

export default ManualBatchingExample;
            

              
                Copy
              
            
          

எப்போது நீங்கள் unstable_batchedUpdates ஐ (எச்சரிக்கையுடன்) கருத்தில் கொள்ளலாம்?

• ரியாக்ட் அல்லாத குறியீட்டுடன் ஒருங்கிணைப்பு: ரியாக்ட்டின் சிந்தெடிக் ஈவென்ட் சிஸ்டத்தைத் தவிர்க்கும் ரியாக்ட் அல்லாத லைப்ரரிகள் அல்லது தனிப்பயன் ஈவென்ட் அமைப்புகளால் ஸ்டேட் புதுப்பிப்புகள் தூண்டப்படும் ஒரு பெரிய பயன்பாட்டில் ரியாக்ட் காம்பொனென்ட்களை ஒருங்கிணைக்கிறீர்கள், மற்றும் நீங்கள் ரியாக்ட் 18-ஐ விட பழைய பதிப்பில் இருந்தால், இது உங்களுக்குத் தேவைப்படலாம்.
• குறிப்பிட்ட மூன்றாம் தரப்பு லைப்ரரிகள்: எப்போதாவது, மூன்றாம் தரப்பு லைப்ரரிகள் தானியங்கி பேட்சிங்கைத் தவிர்க்கும் வழிகளில் ரியாக்ட் ஸ்டேட்டுடன் தொடர்பு கொள்ளலாம்.

இருப்பினும், ரியாக்ட் 18-இன் உலகளாவிய தானியங்கி பேட்சிங்கின் வருகையுடன், unstable_batchedUpdates-இன் தேவை பெருமளவில் குறைந்துவிட்டது. நவீன அணுகுமுறை ரியாக்ட்டின் உள்ளமைக்கப்பட்ட மேம்படுத்தல்களை நம்புவதாகும்.

ரீ-ரெண்டர்கள் மற்றும் பேட்சிங் ஆகியவற்றைப் புரிந்துகொள்ளுதல்

பேட்சிங்கை முழுமையாகப் பாராட்ட, ரியாக்ட்டில் ஒரு ரீ-ரெண்டரைத் தூண்டுவது எது மற்றும் பேட்சிங் எவ்வாறு தலையிடுகிறது என்பதைப் புரிந்துகொள்வது அவசியம்.

ஒரு ரீ-ரெண்டரை ஏற்படுத்துவது எது?

• ஸ்டேட் மாற்றங்கள்: ஒரு ஸ்டேட் செட்டர் செயல்பாட்டை அழைப்பது (எ.கா., setCount(5)) மிகவும் பொதுவான தூண்டுதலாகும்.
• ப்ராப் மாற்றங்கள்: ஒரு பெற்றோர் காம்பொனென்ட் ரீ-ரெண்டர் ஆகி ஒரு குழந்தை காம்பொனென்ட்டுக்கு புதிய ப்ராப்ஸ்களை அனுப்பும்போது, குழந்தை ரீ-ரெண்டர் ஆகலாம்.
• சூழல் மாற்றங்கள்: ஒரு காம்பொனென்ட் சூழலைப் பயன்படுத்தினால் மற்றும் சூழல் மதிப்பு மாறினால், அது ரீ-ரெண்டர் ஆகும்.
• கட்டாயப் புதுப்பிப்பு: பொதுவாக ஊக்கமளிக்கப்படாத போதிலும், forceUpdate() வெளிப்படையாக ஒரு ரீ-ரெண்டரைத் தூண்டுகிறது.

பேட்சிங் ரீ-ரெண்டர்களை எவ்வாறு பாதிக்கிறது:

count மற்றும் value-ஐ நம்பியிருக்கும் ஒரு காம்பொனென்ட் உங்களிடம் இருப்பதாக கற்பனை செய்து பாருங்கள். பேட்சிங் இல்லாமல், setCount அழைக்கப்பட்டு, பின்னர் உடனடியாக setValue அழைக்கப்பட்டால் (எ.கா., தனித்தனி மைக்ரோடாஸ்க்குகள் அல்லது டைம்அவுட்களில்), ரியாக்ட் இவ்வாறு செயல்படலாம்:

1. setCount-ஐ செயலாக்குதல், ஒரு ரீ-ரெண்டரைத் திட்டமிடுதல்.
2. setValue-ஐ செயலாக்குதல், மற்றொரு ரீ-ரெண்டரைத் திட்டமிடுதல்.
3. முதல் ரீ-ரெண்டரைச் செய்தல்.
4. இரண்டாவது ரீ-ரெண்டரைச் செய்தல்.

பேட்சிங்குடன், ரியாக்ட் திறம்பட:

1. setCount-ஐ செயலாக்குகிறது, அதை நிலுவையில் உள்ள புதுப்பிப்புகளின் வரிசையில் சேர்க்கிறது.
2. setValue-ஐ செயலாக்குகிறது, அதை வரிசையில் சேர்க்கிறது.
3. தற்போதைய ஈவென்ட் லூப் அல்லது மைக்ரோடாஸ்க் வரிசை அழிக்கப்பட்டவுடன் (அல்லது ரியாக்ட் கமிட் செய்ய முடிவு செய்யும் போது), ரியாக்ட் அந்த காம்பொனென்ட்டுக்கு (அல்லது அதன் மூதாதையர்களுக்கு) நிலுவையில் உள்ள அனைத்து புதுப்பிப்புகளையும் குழுவாக்கி ஒரே ஒரு ரீ-ரெண்டரைத் திட்டமிடுகிறது.

கன்கரண்ட் அம்சங்களின் பங்கு

ரியாக்ட் 18-இன் கன்கரண்ட் அம்சங்கள் உலகளாவிய தானியங்கி பேட்சிங்கின் பின்னணியில் உள்ள இயந்திரமாகும். கன்கரண்ட் ரெண்டரிங், ரியாக்ட்டை ரெண்டரிங் பணிகளை குறுக்கிட, இடைநிறுத்த மற்றும் மீண்டும் தொடங்க அனுமதிக்கிறது. இந்த திறன் ரியாக்ட்டை DOM-க்கு புதுப்பிப்புகளை எவ்வாறு மற்றும் எப்போது கமிட் செய்கிறது என்பதில் புத்திசாலித்தனமாக இருக்க உதவுகிறது. ஒரு ஒற்றை, தடுக்கும் செயல்முறையாக இல்லாமல், ரெண்டரிங் மிகவும் நுணுக்கமானதாகவும், குறுக்கிடக்கூடியதாகவும் மாறுகிறது, இது UI-க்கு கமிட் செய்வதற்கு முன்பு பல புதுப்பிப்புகளை ஒருங்கிணைப்பதை ரியாக்ட்டுக்கு எளிதாக்குகிறது.

ரியாக்ட் ஒரு ரெண்டரைச் செய்ய முடிவு செய்யும் போது, கடைசி கமிட்டிற்குப் பிறகு நிகழ்ந்த அனைத்து நிலுவையிலுள்ள ஸ்டேட் புதுப்பிப்புகளையும் அது பார்க்கிறது. கன்கரண்ட் அம்சங்களுடன், முக்கிய த்ரெட்டை நீண்ட காலத்திற்குத் தடுக்காமல் இந்த புதுப்பிப்புகளை மிகவும் திறம்பட குழுவாக்க முடியும். இது அசிங்க்ரோனஸ் புதுப்பிப்புகளின் தானியங்கி பேட்சிங்கை ஆதரிக்கும் ஒரு அடிப்படை மாற்றமாகும்.

நடைமுறை எடுத்துக்காட்டுகள் மற்றும் பயன்பாட்டு வழக்குகள்

ஸ்டேட் பேட்சிங்கைப் புரிந்துகொள்வதும் பயன்படுத்துவதும் பயனளிக்கும் சில பொதுவான சூழ்நிலைகளை ஆராய்வோம்:

1. பல உள்ளீட்டு புலங்களைக் கொண்ட படிவங்கள்

ஒரு பயனர் ஒரு படிவத்தை நிரப்பும்போது, ஒவ்வொரு கீஸ்ட்ரோக்கும் அந்த உள்ளீட்டுப் புலத்திற்கான தொடர்புடைய ஸ்டேட் மாறிக்கு அடிக்கடி புதுப்பிக்கிறது. ஒரு சிக்கலான படிவத்தில், இது பல தனிப்பட்ட ஸ்டேட் புதுப்பிப்புகளுக்கும் சாத்தியமான ரீ-ரெண்டர்களுக்கும் வழிவகுக்கும். தனிப்பட்ட உள்ளீட்டுப் புதுப்பிப்புகள் ரியாக்ட்டின் டிஃப்பிங் அல்காரிதம் மூலம் மேம்படுத்தப்பட்டாலும், பேட்சிங் ஒட்டுமொத்த செயல்பாட்டைக் குறைக்க உதவுகிறது.

            import React, { useState } from 'react';

function UserProfileForm() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  const [age, setAge] = useState(0);

  // In React 18+, all these setState calls within a single event handler
  // will be batched into one re-render.
  const handleNameChange = (e) => setName(e.target.value);
  const handleEmailChange = (e) => setEmail(e.target.value);
  const handleAgeChange = (e) => setAge(parseInt(e.target.value, 10) || 0);

  // A single function to update multiple fields based on event target
  const handleInputChange = (event) => {
    const { name, value } = event.target;
    if (name === 'name') setName(value);
    else if (name === 'email') setEmail(value);
    else if (name === 'age') setAge(parseInt(value, 10) || 0);
  };

  return (
    

      

        Name:
        
      
      

        Email:
        
      
      

        Age:
        
      
      {/* Displaying current state for demonstration */}
      
Current Name: {name}
      
Current Email: {email}
      
Current Age: {age}
    
  );
}

export default UserProfileForm;
            

              
                Copy
              
            
          

ரியாக்ட் 18+-இல், இந்த புலங்களில் ஏதேனும் ஒன்றில் உள்ள ஒவ்வொரு கீஸ்ட்ரோக்கும் ஒரு ஸ்டேட் புதுப்பிப்பைத் தூண்டும். இருப்பினும், இவை அனைத்தும் ஒரே சிந்தெடிக் ஈவென்ட் ஹேண்ட்லர் சங்கிலிக்குள் இருப்பதால், ரியாக்ட் அவற்றை பேட்ச் செய்யும். உங்களிடம் தனித்தனி ஹேண்ட்லர்கள் இருந்தாலும், அவை ஒரே ஈவென்ட் லூப் திருப்பத்தில் நிகழ்ந்தால் ரியாக்ட் 18 அவற்றை பேட்ச் செய்யும்.

2. தரவுப் பெறுதல் மற்றும் புதுப்பிப்புகள்

தரவைப் பெற்ற பிறகு, பதிலின் அடிப்படையில் நீங்கள் பல ஸ்டேட் மாறிகளைப் புதுப்பிக்கலாம். இந்த தொடர்ச்சியான புதுப்பிப்புகள் ரீ-ரெண்டர்களின் வெடிப்பை ஏற்படுத்தாது என்பதை பேட்சிங் உறுதி செய்கிறது.

            import React, { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchUserData = async () => {
      try {
        // Simulate API call
        await new Promise(resolve => setTimeout(resolve, 1500));
        const response = await fetch(`https://api.example.com/users/${userId}`);
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const data = await response.json();

        // In React 18+, these updates are batched into a single re-render.
        setUser(data);
        setIsLoading(false);
        setError(null);
      } catch (err) {
        setError(err.message);
        setIsLoading(false);
        setUser(null);
      }
    };

    fetchUserData();
  }, [userId]);

  if (isLoading) {
    return 
Loading user data...
;
  }

  if (error) {
    return 
Error: {error}
;
  }

  if (!user) {
    return 
No user data available.
;
  }

  return (
    

      
{user.name}
      
Email: {user.email}
      {/* Other user details */}
    
  );
}

export default UserProfile;
            

              
                Copy
              
            
          

இந்த `useEffect` ஹூக்கில், அசிங்க்ரோனஸ் தரவுப் பெறுதல் மற்றும் செயலாக்கத்திற்குப் பிறகு, மூன்று ஸ்டேட் புதுப்பிப்புகள் நிகழ்கின்றன: setUser, setIsLoading, மற்றும் setError. ரியாக்ட் 18-இன் தானியங்கி பேட்சிங்கிற்கு நன்றி, தரவு வெற்றிகரமாகப் பெறப்பட்ட பிறகு அல்லது ஒரு பிழை ஏற்பட்ட பிறகு இந்த மூன்று புதுப்பிப்புகளும் ஒரே ஒரு UI ரீ-ரெண்டரை மட்டுமே தூண்டும்.

3. அனிமேஷன்கள் மற்றும் மாற்றங்கள்

காலப்போக்கில் பல ஸ்டேட் மாற்றங்களை உள்ளடக்கிய அனிமேஷன்களைச் செயல்படுத்தும்போது (எ.கா., ஒரு தனிமத்தின் நிலை, ஒளிபுகாநிலை மற்றும் அளவை அனிமேட் செய்தல்), மென்மையான காட்சி மாற்றங்களை உறுதிப்படுத்த பேட்சிங் முக்கியமானது. ஒவ்வொரு சிறிய அனிமேஷன் படியும் ஒரு ரீ-ரெண்டரை ஏற்படுத்தினால், அனிமேஷன் பெரும்பாலும் சீரற்றதாகத் தோன்றும்.

அர்ப்பணிக்கப்பட்ட அனிமேஷன் லைப்ரரிகள் பெரும்பாலும் அவற்றின் சொந்த ரெண்டரிங் மேம்படுத்தல்களைக் கையாளும் போது, ரியாக்ட்டின் பேட்சிங்கைப் புரிந்துகொள்வது தனிப்பயன் அனிமேஷன்களை உருவாக்கும்போது அல்லது அவற்றுடன் ஒருங்கிணைக்கும்போது உதவுகிறது.

            import React, { useState, useEffect, useRef } from 'react';

function AnimatedBox() {
  const [position, setPosition] = useState({ x: 0, y: 0 });
  const [opacity, setOpacity] = useState(1);
  const animationFrameId = useRef(null);

  const animate = () => {
    setPosition(currentPos => {
      const newX = currentPos.x + 5;
      const newY = currentPos.y + 5;
      // If we reach the end, stop the animation
      if (newX > 200) {
        // Cancel the next frame request
        if (animationFrameId.current) {
          cancelAnimationFrame(animationFrameId.current);
        }
        // Optionally fade out
        setOpacity(0);
        return currentPos;
      }
      // In React 18+, setting position and opacity here
      // within the same animation frame processing turn
      // will be batched.
      // Note: For very rapid, sequential updates within the *same* animation frame,
      // direct manipulation or ref updates might be considered, but for typical
      // 'animate in steps' scenarios, batching is powerful.
      return { x: newX, y: newY };
    });
  };

  useEffect(() => {
    // Start animation on mount
    animationFrameId.current = requestAnimationFrame(animate);
    return () => {
      // Cleanup: cancel animation frame if component unmounts
      if (animationFrameId.current) {
        cancelAnimationFrame(animationFrameId.current);
      }
    };
  }, []); // Empty dependency array means this runs once on mount

  return (
    

  );
}

export default AnimatedBox;
            

              
                Copy
              
            
          

இந்த எளிமைப்படுத்தப்பட்ட அனிமேஷன் எடுத்துக்காட்டில், requestAnimationFrame பயன்படுத்தப்படுகிறது. ரியாக்ட் 18 animate செயல்பாட்டிற்குள் நிகழும் ஸ்டேட் புதுப்பிப்புகளை தானாகவே பேட்ச் செய்கிறது, இது பெட்டி நகர்ந்து, குறைவான ரீ-ரெண்டர்களுடன் மங்கிவிடுவதை உறுதிசெய்கிறது, இது ஒரு மென்மையான அனிமேஷனுக்கு பங்களிக்கிறது.

ஸ்டேட் மேலாண்மை மற்றும் பேட்சிங்கிற்கான சிறந்த நடைமுறைகள்

• ரியாக்ட் 18+-ஐப் பயன்படுத்துங்கள்: நீங்கள் ஒரு புதிய திட்டத்தைத் தொடங்குகிறீர்கள் அல்லது மேம்படுத்த முடியும் என்றால், ரியாக்ட் 18-க்கு மாறுங்கள், இதன் மூலம் உலகளாவிய தானியங்கி பேட்சிங்கின் பலனைப் பெறலாம். ஸ்டேட் புதுப்பிப்புகள் தொடர்பான செயல்திறன் மேம்படுத்தலுக்கு நீங்கள் எடுக்கக்கூடிய மிக முக்கியமான படி இதுவாகும்.
• உங்கள் தூண்டுதல்களைப் புரிந்து கொள்ளுங்கள்: உங்கள் ஸ்டேட் புதுப்பிப்புகள் எங்கிருந்து வருகின்றன என்பதை அறிந்து கொள்ளுங்கள். அவை சிந்தெடிக் ஈவென்ட் ஹேண்ட்லர்களுக்குள் இருந்தால், அவை ஏற்கனவே பேட்ச் செய்யப்பட்டிருக்கலாம். அவை பழைய அசிங்க்ரோனஸ் சூழல்களில் இருந்தால், ரியாக்ட் 18 இப்போது அவற்றை கையாளும்.
• ஃபங்ஷனல் அப்டேட்களை விரும்புங்கள்: புதிய ஸ்டேட் முந்தைய ஸ்டேட்டைச் சார்ந்திருக்கும்போது, ஃபங்ஷனல் அப்டேட் படிவத்தைப் பயன்படுத்தவும் (எ.கா., setCount(prevCount => prevCount + 1)). இது பொதுவாக பாதுகாப்பானது, குறிப்பாக அசிங்க்ரோனஸ் செயல்பாடுகள் மற்றும் பேட்சிங்குடன், ஏனெனில் இது நீங்கள் மிகவும் புதுப்பித்த ஸ்டேட் மதிப்புடன் வேலை செய்கிறீர்கள் என்பதை உறுதிப்படுத்துகிறது.
• தேவைப்பட்டாலன்றி கைமுறை பேட்சிங்கைத் தவிர்க்கவும்: unstable_batchedUpdates-ஐ அரிதான நிகழ்வுகளுக்கும் பழைய குறியீடுகளுக்கும் ஒதுக்குங்கள். தானியங்கி பேட்சிங்கை நம்புவது பராமரிக்கக்கூடிய மற்றும் எதிர்காலத்திற்கு ஏற்ற குறியீட்டிற்கு வழிவகுக்கிறது.
• உங்கள் பயன்பாட்டை புரோஃபைல் செய்யுங்கள்: அதிகமாக ரீ-ரெண்டர் செய்யும் காம்பொனென்ட்களை அடையாளம் காண ரியாக்ட் டெவ்டூல்ஸ் புரோஃபைலரைப் பயன்படுத்தவும். பேட்சிங் பல சூழ்நிலைகளை மேம்படுத்தும் போது, முறையற்ற மெமோயைசேஷன் அல்லது ப்ராப் டிரில்லிங் போன்ற பிற காரணிகளும் செயல்திறன் சிக்கல்களை ஏற்படுத்தலாம். புரோஃபைலிங் சரியான தடைகளை சுட்டிக்காட்ட உதவுகிறது.
• தொடர்புடைய ஸ்டேட்டை குழுவாக்குங்கள்: தொடர்புடைய ஸ்டேட்டை ஒரே ஆப்ஜெக்ட்டில் குழுவாக்குவதைக் கருத்தில் கொள்ளுங்கள் அல்லது சிக்கலான ஸ்டேட் படிநிலைகளுக்கு சூழல்/ஸ்டேட் மேலாண்மை லைப்ரரிகளைப் பயன்படுத்தவும். இது தனிப்பட்ட ஸ்டேட் செட்டர்களை பேட்ச் செய்வது பற்றி நேரடியாக இல்லாவிட்டாலும், இது ஸ்டேட் புதுப்பிப்புகளை எளிதாக்கலாம் மற்றும் தேவைப்படும் தனித்தனி `setState` அழைப்புகளின் எண்ணிக்கையைக் குறைக்கலாம்.

பொதுவான சிக்கல்கள் மற்றும் அவற்றை எவ்வாறு தவிர்ப்பது

• ரியாக்ட் பதிப்பைப் புறக்கணித்தல்: அனைத்து ரியாக்ட் பதிப்புகளிலும் பேட்சிங் ஒரே மாதிரியாக செயல்படுகிறது என்று கருதுவது பழைய குறியீட்டுத் தளங்களில் எதிர்பாராத பல ரீ-ரெண்டர்களுக்கு வழிவகுக்கும். நீங்கள் பயன்படுத்தும் ரியாக்ட் பதிப்பைப் பற்றி எப்போதும் எச்சரிக்கையாக இருங்கள்.
• சின்க்ரோனஸ் போன்ற புதுப்பிப்புகளுக்கு `useEffect`-ஐ அதிகமாக நம்புதல்: `useEffect` பக்க விளைவுகளுக்குப் பயன்பட்டாலும், நீங்கள் `useEffect`-க்குள் ஒத்திசைவானதாகத் தோன்றும் விரைவான, நெருங்கிய தொடர்புடைய ஸ்டேட் புதுப்பிப்புகளைத் தூண்டினால், அவற்றை சிறப்பாக பேட்ச் செய்ய முடியுமா என்று கருதுங்கள். ரியாக்ட் 18 இங்கே உதவுகிறது, ஆனால் ஸ்டேட் புதுப்பிப்புகளின் தர்க்கரீதியான குழுவாக்கம் இன்னும் முக்கியமானது.
• புரோஃபைலர் தரவை தவறாகப் புரிந்துகொள்வது: புரோஃபைலரில் பல ஸ்டேட் புதுப்பிப்புகளைப் பார்ப்பது, அவை சரியாக ஒரே கமிட்டில் பேட்ச் செய்யப்பட்டிருந்தால், திறமையற்ற ரெண்டரிங் என்று எப்போதும் அர்த்தமல்ல. ஸ்டேட் புதுப்பிப்புகளின் எண்ணிக்கையை விட கமிட்களின் (ரீ-ரெண்டர்கள்) எண்ணிக்கையில் கவனம் செலுத்துங்கள்.
• சோதனைகள் இல்லாமல் `componentDidUpdate` அல்லது `useEffect`-க்குள் `setState`-ஐப் பயன்படுத்துதல்: கிளாஸ் காம்பொனென்ட்களில், `componentDidUpdate` அல்லது `useEffect`-க்குள் சரியான நிபந்தனைச் சோதனைகள் இல்லாமல் `setState`-ஐ அழைப்பது, பேட்சிங்குடன் கூட, முடிவற்ற ரீ-ரெண்டர் சுழற்சிகளுக்கு வழிவகுக்கும். இதைத் தடுக்க எப்போதும் நிபந்தனைகளைச் சேர்க்கவும்.

முடிவுரை

ஸ்டேட் பேட்சிங் என்பது ரியாக்ட்டில் உள்ள ஒரு சக்திவாய்ந்த, மறைமுகமான மேம்படுத்தலாகும், இது பயன்பாட்டு செயல்திறனைப் பராமரிப்பதில் முக்கிய பங்கு வகிக்கிறது. ரியாக்ட் 18-இல் உலகளாவிய தானியங்கி பேட்சிங் அறிமுகப்படுத்தப்பட்டதன் மூலம், பல்வேறு அசிங்க்ரோனஸ் மூலங்களிலிருந்து வரும் பல ஸ்டேட் புதுப்பிப்புகள் புத்திசாலித்தனமாக ஒரே ரீ-ரெண்டரில் குழுவாக்கப்படுவதால், டெவலப்பர்கள் இப்போது கணிசமாக மென்மையான மற்றும் கணிக்கக்கூடிய அனுபவத்தை அனுபவிக்க முடியும்.

பேட்சிங் எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்வதன் மூலமும், ஃபங்ஷனல் அப்டேட்களைப் பயன்படுத்துதல் மற்றும் ரியாக்ட் 18-இன் திறன்களைப் பயன்படுத்துதல் போன்ற சிறந்த நடைமுறைகளை ஏற்றுக்கொள்வதன் மூலமும், நீங்கள் அதிக பதிலளிக்கக்கூடிய, திறமையான மற்றும் செயல்திறன் மிக்க ரியாக்ட் பயன்பாடுகளை உருவாக்க முடியும். குறிப்பிட்ட மேம்படுத்தல் பகுதிகளை அடையாளம் காண உங்கள் பயன்பாட்டை எப்போதும் புரோஃபைல் செய்ய நினைவில் கொள்ளுங்கள், ஆனால் ரியாக்ட்டின் உள்ளமைக்கப்பட்ட பேட்சிங் பொறிமுறையானது ஒரு குறைபாடற்ற பயனர் அனுபவத்தை நோக்கிய உங்கள் பயணத்தில் ஒரு குறிப்பிடத்தக்க கூட்டாளி என்பதில் நம்பிக்கையுடன் இருங்கள்.

ரியாக்ட் டெவலப்மெண்டில் உங்கள் பயணத்தைத் தொடரும்போது, இந்த செயல்திறன் நுணுக்கங்களுக்கு கவனம் செலுத்துவது சந்தேகத்திற்கு இடமின்றி உங்கள் பயன்பாடுகளின் தரம் மற்றும் பயனர் திருப்தியை உயர்த்தும், உங்கள் பயனர்கள் உலகில் எங்கிருந்தாலும் சரி.